The ability for malware (or a cracker) to remotely exploit vulnerabilities
of infrastructure components, network services, and applications remains a
major threat to cloud services. It is an even greater risk for a public
PaaS and IaaS delivery model where vulnerability, patch, and configuration
management responsibilities remain with the customer. Customers should
remember that in cloud computing environments, the lowest or highest
common denominator of security is shared by all tenants in a multitenant
virtual environment. Hence, the onus is with the customers to understand
the scope of their security management responsibilities. Customers should
demand that CSPs become more transparent about their cloud security
operations to help customers understand and plan complementary security
management functions.By and large, CSPs are responsible for the vulnerability, patch, and
configuration (VPC) management of the infrastructure (networks, hosts,
applications, and storage) that is CSP-managed and operated, as well as
third-party services that they may rely on. However, customers are not
spared from their VPC duties and should understand the VPC aspects for
which they are responsible. A VPC management scope should address
end-to-end security and should include customer-managed systems and
applications that interface with cloud services. As a standard practice,
CSPs may have instituted these programs within their security management
domain, but typically the process is internal to the CSP and is not
apparent to customers. CSPs should assure their customers of their
technical vulnerability management program using ISO/IEC 27002 type control and assurance frameworks.
What is your responsibility in managing vulnerabilities in the
cloud? How does security patch management manifest in cloud services? Who
is responsible for patch and security configuration of the cloud
infrastructure? What options do you have to extend your current security
management processes to cloud services?
The following sections discuss these VPC issues in the SPI delivery
model context, and outline the VPC responsibilities for CSPs and their
customers.
1. Security Vulnerability Management
Vulnerability management is an essential threat management element to help protect
hosts, network devices, and applications from attacks against known
vulnerabilities. Mature organizations have instituted a vulnerability
management process that involves routine scanning of systems connected
to their network, assessing the risks of vulnerabilities to the
organization, and a remediation process (usually feeding into a patch
management program) to address the risks. Organizations using ISO/IEC
27002 are known to address this program using a technical vulnerability
management control objective, which states:
Objective: To reduce risks resulting from exploitation of
published technical vulnerabilities.
Technical vulnerability management should be implemented in an
effective, systematic, and repeatable way with measurements taken to
confirm its effectiveness. These considerations should include
operating systems, and any other applications in use.
Both the customer and the CSP are responsible for vulnerability
management of the cloud infrastructure, depending on the SPI service in
context.
2. Security Patch Management
Similar to vulnerability management, security patch management
is a vital threat management element in protecting hosts,
network devices, and applications from unauthorized users exploiting a
known vulnerability. Patch management processes follow a change
management framework and feeds directly from the actions directed by
your vulnerability management program. Security patch management
mitigates risk to your organization by way of insider and outsider
threats. Hence, SaaS providers should be routinely assessing new
vulnerabilities and patching the firmware and software on all systems
that are involved in delivering the *aaS service to customers.
The scope of patch management responsibility for customers will
have a low-to-high relevance in the order of SaaS, PaaS, and IaaS
services—that is, customers are relieved from patch management duties in
a SaaS environment, whereas they are responsible for managing patches
for the whole stack of software (operating system, applications, and
database) installed and operated on the IaaS platform. Customers are
also responsible for patching their applications deployed on the PaaS
platform.
3. Security Configuration Management
Security configuration management is another significant threat management
practice to protect hosts and network devices from unauthorized users
exploiting any configuration weakness. Security configuration management
is closely related to the vulnerability management program and is a
subset of overall IT configuration management. Protecting the
configuration of the network, host, and application entails monitoring
and access control to critical system and database configuration files,
including OS configuration, firewall policies, network zone
configuration, locally and remotely attached storage, and an access
control management database.
In the SPI service delivery model, configuration management from a
customer responsibility perspective has a low-to-high relevance in the
order of SaaS, PaaS, and IaaS services—that is, SaaS and PaaS service
providers are responsible for configuration management of their
platform, whereas IaaS customers are responsible for configuration
management of the operating system, application, and database hosted on
the IaaS platform. Customers are also responsible for configuration
management of their applications deployed on the PaaS platform.
4. SaaS VPC Management
SaaS VPC management focuses on managing vulnerabilities, security patching,
and system configuration in the CSP-managed infrastructure, as well as
the customer infrastructure interfacing with the SaaS service. Since the
SaaS delivery model is anchored on the premise that the application
service is delivered over the Internet to a web browser running on any
computing device (personal computer, virtual desktop, or mobile device),
it is important to secure the endpoints from which the cloud is
accessed. Hence, a VPC management program should include endpoint VPC
management requirements and should be tailored to the corporate
environment. It is standard practice for most companies to institute a
standard OS image for personal computers that include security tools
such as antivirus, anti-malware, firewall, and automatic patch
management from a central management station.
4.1. SaaS provider responsibilities
The following list represents SaaS VPC scope:
Systems, networks, hosts, applications, and storage that are
owned and operated by the CSP
Systems, networks, hosts, applications, and storage that are
managed by third parties
Personal computers and smartphones owned by the SaaS
employees and contractors
4.2. SaaS customer responsibilities
Because SaaS services are typically delivered to web browsers
and, in some cases, are integrated with customer applications (via an
XML interface), the customer has limited responsibilities for VPC
management of the infrastructure in the cloud. However, SaaS customers
are responsible for VPC management of their systems that interface
with the SaaS service. The responsibilities include:
Personal computers of a SaaS user.
Applications or services that interface with the SaaS
service.
Security testing of the SaaS service. Although SaaS
providers are responsible for vulnerability management of the
software delivered as a service, some enterprise customers can
choose to independently assess the state of application security.
Customers evaluating this independent verification option should
gain the consent of the CSP, because SaaS security testing can be
performed only with the permission and cooperation of the SaaS
vendor. This type of application testing, usually performed by a
third-party tester, may involve an active analysis of the
application and a simulation of real attack scenarios with the
objective of discovering vulnerabilities in the application. This
is a qualitative method, and the scope of testing could vary based
on the identified vulnerability. Hence, it is advisable to verify
and agree on the scope prior to the exercise. This type of testing
can reveal the top web application vulnerabilities that are
categorized as OWASP Top 10 vulnerabilities. SQL injection,
parameter manipulation, cookie poisoning, and cross-site scripting
(XSS) are common types of vulnerabilities found during the
application vulnerability testing cycle.
Note:
The scope of the VPC management program should include browser
security, systems, and applications (on both trusted and untrusted
zones) located at a customer’s premises interfacing with SaaS
services.
5. PaaS VPC Management
PaaS VPC management focuses on VPC management in the CSP-managed
infrastructure, as well as the customer infrastructure interfacing with
the PaaS service. Since applications deployed on a PaaS platform are
accessed from a web browser running on an endpoint device (personal
computer, virtual desktop, or mobile device), the program should include
endpoint VPC management scope.
5.1. PaaS provider responsibilities
Similar to a SaaS model, the PaaS CSP is responsible for VPC
management of the infrastructure that is operated by the CSP, as well
as third-party services that they may rely on. Refer to Section 6.8.4.1 for responsibility
items.
5.2. PaaS customer responsibilities
In addition to the responsibilities outlined in Section 6.8.4.2, PaaS customers are
responsible for VPC management of the applications implemented and
deployed on the PaaS platform. Vulnerabilities or the configuration
weakness of applications deployed on a PaaS platform should be treated
similarly to a standard application operating in your data center
(e.g., private cloud). Software vulnerabilities are introduced by
design flaws or coding errors. Configuration weakness can be
introduced by improper configuration of an application in the area of
authentication and privilege management. In addition, PaaS
applications that rely on third-party web services may simply become
weak and vulnerable by way of vulnerabilities in the third-party
service, and that is out of your control. Although you have the
ability to fix vulnerabilities in the source code of your PaaS
application, you must work with the PaaS vendor or third-party service
providers to fix vulnerabilities or flaws in their services. Hence,
customers should understand the vulnerability disclosure methods,
SLAs, and PaaS policies of third-party service providers. PaaS
customers should follow standard practices embedded in the Software
Development Life Cycle (SDLC), which helps to reduce software
application vulnerabilities. Following are some of the standard
practices:
Application white-box testing
Analyze the source code for vulnerabilities using testing tools that look for
vulnerabilities such as buffer overflows, e.g., Ounce Labs and
Fortify source code analysis tools.
Application black-box testing
This type of testing (performed by testers) requires knowledge
of the application’s functionality. Source code access is
generally not required. This type of testing can reveal OWASP
Top 10 application vulnerabilities, including SQL injection,
parameter manipulation, cookie poisoning, and XSS. For example,
service providers such as Cigital and Veracode.
Application penetration testing
Although PaaS providers are responsible for vulnerability management of the
software platform delivered as a service, some enterprise
customers can choose to independently verify application
platform security. Customers evaluating this independent
verification option should check with their PaaS CSPs first,
because platform testing can be performed only with the
permission and cooperation of the PaaS vendor. This type of
application testing, usually performed by a third-party tester,
involves active analysis of the application and a simulation of
real attack scenarios with the objective of discovering
vulnerabilities in the application. This is a qualitative
method, and the scope of testing could vary based on the
identified vulnerability. Hence, it is advisable to verify and
agree on the scope prior to the exercise. This type of testing
can uncover OWASP Top 10 application vulnerabilities, including
SQL injection, parameter manipulation, cookie
poisoning, and XSS.
Vulnerability alerts
Customers should understand the means by which PaaS
providers, companies, or communities supporting the PaaS
programming language disseminate vulnerability-related
information to customers. PaaS providers can choose email, RSS,
or a web portal to communicate with their customers. Likewise,
you should choose the appropriate methods to stay informed of
any new vulnerability in the platform or the third-party service
providers.
PaaS customers are also responsible for VPC management of their
systems that interface with the PaaS service. These systems
include:
Personal computers of a PaaS user
Browsers used for accessing the PaaS service
Applications located at the customer’s premises that
interface with the PaaS service
